Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/views/SettingsView/NetworkSection.tsx">

<violation number="1" location="src/views/SettingsView/NetworkSection.tsx:57">
P2: This controlled text field saves on every keystroke without local draft state, which can make typing laggy/unreliable and causes excessive IPC/disk writes. Commit on blur (or debounce with local state) instead.</violation>
</file>

<file name="src-tauri/src/adapters/driving/tauri_ipc.rs">

<violation number="1" location="src-tauri/src/adapters/driving/tauri_ipc.rs:537">
P1: `settings_update` expects a `patch`-named argument, but callers send patch fields at the top level, causing IPC argument mismatch and failed settings updates.</violation>
</file>

<file name="src/views/SettingsView/SettingField.tsx">

<violation number="1" location="src/views/SettingsView/SettingField.tsx:55">
P2: This numeric input persists changes on every keystroke, causing repeated `settings_update` IPC calls and config file writes while the user is still typing. Buffer the edit locally and commit on blur (or debounce) to avoid write amplification.</violation>

<violation number="2" location="src/views/SettingsView/SettingField.tsx:55">
P2: Using `Number(e.target.value)` on a number input coerces empty input to `0`, causing accidental config updates when users clear the field.</violation>
</file>

<file name="src/views/SettingsView/GeneralSection.tsx">

<violation number="1" location="src/views/SettingsView/GeneralSection.tsx:37">
P2: The “Browse” control is non-functional (no click handler), and the directory field is read-only, so `downloadDir` cannot be changed from this screen.</violation>
</file>

<file name="src-tauri/src/lib.rs">

<violation number="1" location="src-tauri/src/lib.rs:82">
P1: `settings_get`/`settings_update` are registered before `AppState` is managed, so settings IPC calls will fail at runtime.</violation>
</file>

<file name="src/views/SettingsView/BrowserSection.tsx">

<violation number="1" location="src/views/SettingsView/BrowserSection.tsx:40">
P2: Using `defaultValue` here makes the field stale after `config` refreshes; subsequent blur events can overwrite newer settings with outdated text.</violation>
</file>

<file name="src-tauri/src/adapters/driven/config/toml_config_store.rs">

<violation number="1" location="src-tauri/src/adapters/driven/config/toml_config_store.rs:44">
P1: The config file contains `api_key`, but the temp file is written without explicitly restrictive permissions. This can expose the API key to other local users on permissive filesystem defaults.</violation>

<violation number="2" location="src-tauri/src/adapters/driven/config/toml_config_store.rs:63">
P1: `update_config` is not concurrency-safe: concurrent settings updates can race and lose writes due to unsynchronized read-modify-write on the same file.</violation>
</file>

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src-tauri/src/adapters/driven/config/toml_config_store.rs`:
- Around line 62-66: The update_config read-modify-write in update_config
currently has no synchronization and can be lost by concurrent callers; wrap the
entire sequence (read_or_default -> apply_patch -> write_config) with a durable
lock (e.g., a process-level file lock or a Mutex stored on the config adapter)
to serialize transactions. Locate update_config, read_or_default, write_config,
and apply_patch and acquire the lock before calling read_or_default and hold it
until after write_config returns (release on success/error); prefer a file lock
(flock or fs2) for cross-process safety, or an internal Mutex for in-process
only, and ensure errors while locking are converted to DomainError.

In `@src-tauri/src/adapters/driving/tauri_ipc.rs`:
- Around line 377-382: The SettingsDto currently includes the raw api_key field
(see fields
web_interface_enabled/web_interface_port/rest_api_enabled/api_key/websocket_enabled)
and settings_get/settings_update serialize and return it to the renderer; change
SettingsDto so it does NOT expose the secret directly: remove or replace the
api_key string with a masked placeholder (e.g. "*****") or a boolean hasApiKey
flag, and update any code paths in settings_get and settings_update (and related
code around the other occurrences you flagged) to return the masked/flagged
value instead; implement a separate explicit IPC command (e.g. reveal_api_key /
regenerate_api_key / copy_api_key) that performs secure server-side
retrieval/regeneration and only returns the real secret when authorized.

In `@src-tauri/src/application/commands/update_config.rs`:
- Around line 10-63: validate_patch currently only checks the incoming
ConfigPatch fields, letting invalid combined state (e.g. proxy_type set to
"http"/"socks5" while proxy_url is empty) be persisted; update
handle_update_config to merge cmd.patch with the current config from
config_store() to produce the post-merge AppConfig, validate that merged config
before calling config_store().update_config, and only persist if validation
passes (either add a new validate_config(AppConfig) or adapt validate_patch to
accept/validate the fully-merged config); reference validate_patch,
handle_update_config, config_store().update_config, Cmd.patch and AppConfig when
locating the changes.

In `@src-tauri/src/lib.rs`:
- Around line 82-83: Create and manage the AppState instance before registering
the settings IPC handlers: instantiate your AppState (ensuring it meets Send +
Sync requirements or is wrapped in Arc/Mutex as needed) and call the builder's
manage method (app.manage(state) / builder.manage(state)) prior to registering
settings_get and settings_update so the handlers receiving State<'_, AppState>
have a valid managed state at runtime; update the init sequence to construct the
state and call manage(...) before the handler registration that references
settings_get and settings_update.

In `@src/views/SettingsView/AppearanceSection.tsx`:
- Around line 63-75: The accent swatch buttons only use visual border styling to
indicate selection; update the button elements rendered from ACCENT_PRESETS in
AppearanceSection (where handleChange is called and compared to
config.accentColor) to expose the active state to assistive tech by adding a
proper accessible state — e.g., set aria-pressed={config.accentColor ===
preset.value} or convert the group to a radio role with role="radiogroup" on the
container and role="radio" plus aria-checked on each item — and ensure keyboard
activation still calls handleChange('accentColor', preset.value).

In `@src/views/SettingsView/BrowserSection.tsx`:
- Around line 38-64: The textareas in BrowserSection use defaultValue so they
don't update when config changes; replace them with controlled inputs: add
useState hooks (e.g., excludedDomainsText, excludedExtensionsText) initialized
from config.excludedDomains.join(', ') / config.excludedExtensions.join(', '),
add a useEffect that updates those state strings when config changes, set each
textarea's value to the corresponding state, update state in onChange, and keep
the existing onBlur parsing to call handleChange('excludedDomains', ...) and
handleChange('excludedExtensions', ...). This mirrors the controlled pattern
used in GeneralSection and ensures the UI stays in sync with config updates.

In `@src/views/SettingsView/GeneralSection.tsx`:
- Around line 37-39: The Browse Button renders an interactive control with no
action; either wire it to a folder-picker handler or make it non-interactive
until implemented. Add an onClick handler (e.g., handleBrowseFolder) on the
Button (the one rendering FolderOpen) that opens a hidden file input configured
for directory selection (input type="file" with webkitdirectory / directory
attributes, or call the platform-specific API if running in Electron) and handle
the selected path(s) in your component state, or alternatively set the Button's
disabled prop and update any accessibility labels to reflect the disabled state
until the folder selection feature is implemented.

In `@src/views/SettingsView/NetworkSection.tsx`:
- Around line 56-69: The User agent and proxy inputs currently write to config
on every keystroke (Input components using value={config.userAgent} and
value={config.proxyUrl} with onChange calling handleChange -> mutate), causing
an IPC/config write per character; change these to use local draft state (e.g.,
useState hooks like proxyDraft and userAgentDraft) bound to the Input values and
update drafts on onChange, then call handleChange/mutate only on onBlur (or
after a debounced timeout or an explicit Save/Apply button) to persist changes;
update the Input handlers and the component initialization to seed drafts from
config and ensure the blur/debounce/save path calls the existing
handleChange('proxyUrl', ...) and handleChange('userAgent', ...) so persistence
logic stays centralized.

In `@src/views/SettingsView/SettingField.tsx`:
- Around line 48-55: The input currently calls onChange(Number(...)) on every
keystroke; change SettingField to buffer edits in a local state (e.g., const
[localValue, setLocalValue] = useState(value) with a useEffect to sync incoming
value), bind the Input value to localValue and update it in onChange
(setLocalValue), then call the external onChange only when the user commits
(onBlur and onKeyDown for Enter) converting and validating the value against
min/max/step before calling onChange(Number(localValue)); keep the prop names
value, onChange, min, max, step and the Input component usage to locate changes.
- Around line 13-18: The visible label/description text in SettingField is not
programmatically associated with the form control; update the component to
generate or accept a stable id (useId or an id prop) and pass that id to the
Switch and Input components, set the label wrapper to use htmlFor or
aria-labelledby pointing to that id, and add aria-describedby linking to the
description element (if present); ensure you update both the checkbox row
(Switch, checked/onCheckedChange) and the input row (Input, value/onChange) so
clicking the text focuses/toggles the control and screen readers read the
description.

In `@src/views/SettingsView/SettingsView.tsx`:
- Around line 63-77: The current check conflates loading and error: replace the
combined condition so only isLoading renders the skeletons and handle a missing
config as an error state; when config is falsy and isLoading is false render an
error UI with a message and a retry control that calls the same settings_get (or
the existing fetch/settings loader) to re-attempt the request, and ensure any
error details from the failed settings_get are surfaced to the user or stored in
state for display.

---

Nitpick comments:
In `@src-tauri/src/adapters/driven/event/tauri_bridge.rs`:
- Line 37: Add a unit test to cover the new DomainEvent::SettingsUpdated mapping
in tauri_bridge.rs: locate the match arm that maps DomainEvent::SettingsUpdated
=> "settings-updated" (e.g., in the function that converts DomainEvent to a
Tauri event name/payload) and add a test that constructs
DomainEvent::SettingsUpdated, invokes the conversion function (or the public API
that produces the (name, payload) pair), and asserts the name equals
"settings-updated" and the payload equals an empty object ({}). Ensure the test
is placed alongside existing tests in the same module and follows the project’s
test conventions so this mapping is guarded against regressions.

In `@src/views/SettingsView/__tests__/SettingsView.test.tsx`:
- Around line 14-16: Update the mock for '@tauri-apps/api/event' in
SettingsView.test.tsx so the mocked listen call asserts the exact event name;
replace the current looser vi.mock that returns a generic listen with a
mockImplementation on listen that checks its first argument equals
"settings-updated" (and then returns a resolved cleanup function), referencing
the existing vi.mock(...) and listen mock to locate where to change.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/views/SettingsView/AppearanceSection.tsx`:
- Around line 19-21: Update the user-facing locale labels in the
AppearanceSection component: replace the 'label' string for the French locale
from "Francais" to "Français" and for the Spanish locale from "Espanol" to
"Español" so the displayed names use correct diacritics; locate the array of
locale objects in AppearanceSection (the entries with value 'fr' and 'es') and
update their label properties accordingly.

In `@src/views/SettingsView/DownloadsSection.tsx`:
- Around line 46-50: The label "Speed limit (MB/s)" and the onChange conversion
in the DownloadsSection (value speedLimitMb, onChange ->
handleChange('speedLimitBytesPerSec', ...)) are inconsistent: the code
multiplies by 1,048,576 (MiB) but the label says MB; update either the label to
"MiB/s" to match the binary conversion or change the multiplier to 1_000_000 to
use decimal MB, and keep the conversion logic otherwise unchanged so
handleChange('speedLimitBytesPerSec', ...) receives the correct bytes/sec.

---

Outside diff comments:
In `@src/stores/settingsStore.ts`:
- Around line 22-33: The optimistic update in updateConfig mutates state before
the remote call and never rolls back on error; modify updateConfig to snapshot
the previous config (e.g., const prev = get().config) before set(...), then if
tauriInvoke('settings_update', { patch: partial }) throws revert to the snapshot
via set({ config: prev }) and still set the error message, and keep the
isLoading toggles as now; ensure you reference the updateConfig function and the
'settings_update' invoke call when implementing the rollback.

---

Nitpick comments:
In `@src/views/SettingsView/RemoteAccessSection.tsx`:
- Around line 102-107: Add a confirmation step before regenerating the API key
by wrapping the Button's onClick handler (the Regenerate API key button that
currently calls handleChange('apiKey', crypto.randomUUID())) with a user
confirmation flow: show a confirmation dialog/modal (or call window.confirm)
asking the user to confirm the destructive action, and only invoke
handleChange('apiKey', crypto.randomUUID()) if the user confirms; keep the
dialog message clear about breaking existing clients and optionally provide a
cancel path.

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src-tauri/src/adapters/driven/config/toml_config_store.rs">

<violation number="1" location="src-tauri/src/adapters/driven/config/toml_config_store.rs:68">
P2: The new mutex only guards `update_config`, but `get_config` can also write `config.toml` without that lock. Concurrent calls can still race and overwrite updates.</violation>
</file>

<file name="src/views/SettingsView/SettingField.tsx">

<violation number="1" location="src/views/SettingsView/SettingField.tsx:55">
P2: After clamping, the local input state is not updated, so the field can keep showing an invalid/out-of-range number when parent value doesn't change.</violation>
</file>

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src-tauri/src/adapters/driven/config/toml_config_store.rs`:
- Around line 44-53: The temp-file write currently uses std::fs::write which
creates the file with platform-default permissions; change the tmp file creation
to use std::fs::OpenOptions with std::os::unix::fs::OpenOptionsExt::mode(0o600)
so the temp config file is created owner-read/write only, then write the TOML
content via that opened file (e.g., open tmp_path with
OpenOptions::new().create(true).write(true).truncate(true).mode(0o600), write
the serialized content, flush, close) and finally rename tmp_path to self.path
as before; update the block around ConfigDto::from(...),
toml::to_string_pretty(...), tmp_path and the rename call to use this secure
OpenOptions-based write.

In `@src/views/SettingsView/AppearanceSection.tsx`:
- Around line 43-57: The Theme and Language Select controls lack programmatic
accessible names; update the SelectTrigger (or the Select component) for the
Theme select (which uses value={config.theme} and onValueChange={(v: ThemeMode)
=> handleChange('theme', v)}) to include an explicit accessible name (e.g., add
aria-label="Theme" or aria-labelledby pointing to its label) and do the same for
the Language select (the other Select block using handleChange('language',
...)). Ensure the aria attribute is applied to the interactive element
(SelectTrigger or the outer Select) so screen readers associate the visible <p>
label with the control.

In `@src/views/SettingsView/SettingField.tsx`:
- Around line 51-56: commit() currently clamps to min/max but can emit values
that don't align to the configured step; adjust the numeric value to the nearest
valid step before clamping/emitting. In the commit function use step (if truthy)
to compute an aligned value by using a base (min ?? 0), computing
Math.round((num - base)/step) * step + base, then clamp that aligned value with
min/max, call setLocalValue(String(alignedClamped)) and
onChange(alignedClamped); keep existing flow and handle step===0/undefined by
falling back to the current behavior.

---

Duplicate comments:
In `@src/views/SettingsView/SettingField.tsx`:
- Around line 17-20: The description paragraph rendered in SettingField (label,
description) isn't referenced by the control, so add an ID for the description
(e.g. const descId = `${id}-description`) and set aria-describedby={description
? descId : undefined} on the Switch component (the Switch props in SettingField:
id, checked, onCheckedChange) and give the <p> that renders {description} the
id={descId}; repeat the same pattern for the other similar block (the second
SettingField instance around the other description rendering) so screen readers
can associate helper text with the control.

---

Nitpick comments:
In `@src-tauri/src/adapters/driven/config/toml_config_store.rs`:
- Around line 27-35: The pre-check using self.path.exists() in read_or_default
(and similarly in get_config) should be removed to avoid TOCTOU; instead call
std::fs::read_to_string(&self.path) (or std::fs::read) directly and match the
resulting io::Error: if the error.kind() == io::ErrorKind::NotFound return
Ok(AppConfig::default()) (or appropriate default/None for get_config), otherwise
map the error to DomainError::StorageError as done now; apply the same pattern
when parsing toml (ConfigDto from_str) so only actual NotFound is special-cased
and all other I/O/parsing errors remain mapped to DomainError::StorageError.

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@src-tauri/src/adapters/driven/config/toml_config_store.rs`:
- Around line 69-77: The temp-file write path currently calls file.write_all and
file.flush but then immediately uses std::fs::rename(&tmp_path, &self.path);
update the sequence in the function that performs the write (the block using
file.write_all, file.flush, tmp_path and self.path) to call file.sync_all()
after flush and before std::fs::rename, and map any sync_all() error into the
same DomainError::StorageError pattern so the rename only happens after the file
is durably persisted.

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src-tauri/src/adapters/driven/config/toml_config_store.rs">

<violation number="1" location="src-tauri/src/adapters/driven/config/toml_config_store.rs:72">
P2: `flush()` does not make file writes durable for `File`; use `sync_all()` before rename to preserve atomic-write guarantees across crashes.</violation>
</file>